Subject: Comments on Flow Control Proposal

From: [email-masked] (Shannon Nix)
Date: Mon, 07 Feb 94 17:40:08 EST

Peter,

Good work on the FC proposal!

I have the following comments:

1.  The window size adjustment is completely receiver controlled.  I would
    like to see some feedback from the sender on a pacing request that 
    indicates something like:

        "for the last pacing window, I could have utilized a larger
         window, had you granted it."

    This makes it much easier (possible??) for a receiving implementation 
    to establish an upper bound on the window size which approximates the
    optimum window size for the turn-around propagation delay in the network.

    If a receiving implementation relies solely on internal buffer and queueing
    conditions, then there are cases where the window size may be incremented
    well beyond:
       a) the capacity of the sender to deliver 
       b) the window required to utilize the network throughput during
          the pacing request/reply turnaround cycle.

2.  I oppose supporting both the NONE and ONOFF level of flow control.  There is
    no way for a receiving implementation to enforce a deterministic buffer     
    management policy using either mechanism.

    I agree with making the FIXED the minimum for base-level support.  I 
    also agree that that base-level implementations have the right to tear
    down the transport if a sub-base algorithm is negotiated.

    I just don't see the need of having two sub-base flow control algorithms:

    I propose having a single sub-base algorithm (also the default for no CAP   
    EX) This could be either.

    1.  NONE... because ONOFF really doesn't solve the problem so why bother.   
        This doesn't break the 6611 since it doesn't send ONOFF.

    2.  Must at least respond to ONOFF (6611 like)

    I would also favor not negotiating either NONE or ONOFF in CAP EX.  
    Rather,stipulate that the only way to negotiate a sub-base algorithm is 
    for one of the parties to not support CAP EX.  I don't think we should 
    encourage any additional sub-base implementations.

Rgds, Shannon